It has been known in the field of networked communications to deploy virtual connections such as Soft Permanent Virtual Connections (SPVCs) to provision end-to-end communications in Asynchronous Transfer Mode (ATM) networks and in Frame Relay (FR) networks. As known to those in this art, SPVCs are characterized in that they can be configured from edge network nodes to which customer equipment or other access circuits may be connected. Also, virtual connections such as SPVCs allow for communications that can be re-routed automatically in the event of a datapath failure. With the advent and increasing adoption of Internet Protocol suite (IP) networks, mechanisms have been devised to permit the end-to-end establishment of traffic flows or connections originating from ATM compliant networks or other networks over IP backbone networks. For instance, ATM pseudowires (PWs) in Multiprotocol Label Switching (MPLS) networks have been employed to route, signal and forward ATM originated traffic end-to-end over such networks.
Thus, ATM Forum document af-cs-0197.000 entitled “ATM-MPLS Network Interworking Signalling Specification Version 1.0” and dated August 2003, teaches the tunneling of ATM routing and signaling information via the MPLS protocol. The latter teaching uses ATM as the signaling protocol to establish a logical ATM pipe or pseudowire type in an MPLS backbone network. This document makes provision for the negotiation of an encapsulation mode for the forwarded traffic. As known to those in this art, an encapsulation mode defines a means for carrying one protocol packet inside another packet of a differing protocol. The carried packet retains its original packet header information and format unchanged. However, the document does not provide support for the selection of datapath interworking, e.g. FRF.5 and FRF.8.1 FR-ATM interworking, since the architecture in question is dedicated and preconfigured for given end systems or access circuits that are ATM compliant. By datapath interworking, those skilled in this art will understand that the packet format of an originating network environment will be translated or adapted into another packet format according to the protocol of the transiting network, based on knowledge of the higher layer payload carried inside the packet. In other words, the architecture taught in the foregoing document is not described as applying to networks where technologies other than ATM are used at the access circuit endpoints. Finally, the reference in question makes use of the ATM signaling protocol to set up the pseudowire and not an MPLS signaling protocol such as LDP.
As known to those skilled in the art of networked communications, a draft document of the Internet Engineering Task Force (IETF), namely the Network Working Group Internet Draft entitled “Soft Permanent Virtual Circuit Interworking between PWE3 and ATM” which is dated July 2004 and is authored by G. Swallow and M. Spiegel (draft-swallow-pew3-spvc-iw-01.txt, hereafter the “SPVC Interworking Draft” which is hereby incorporated by reference herein), proposed an interworking methodology between Private Network Node Interface (PNNI) SPVC signaling and the Label Distribution Protocol (LDP) as extended by various other IETF drafts. These other IETF drafts, also known to those in this art, are entitled “Pseudowire Setup and Maintenance using LDP” which is dated December 2004 and is authored by L. Martini and E. Rosen (draft-ietf-pew3-control-protocol-14.txt) and “Provisioning Models and Endpoint Identifiers in L2VPN Signalling” which is dated September 2004 and is authored by E. Rosen and V. Radoaca (draft-ietf-12vpn-signaling-02.txt), and these drafts are also incorporated by reference herein. However, the foregoing prior art does not provide a mechanism whereby an MPLS/IP interface edge node of an MPLS network can in every case determine or infer, solely from the contents of an ATM connection setup message, the type of encapsulation to use on the pseudowire over the MPLS network. Likewise, the interface node in question according to the teachings of the prior art cannot in every case determine or infer what type of datapath interworking to adopt, if any, solely from the contents of the ATM connection setup message. Moreover, the foregoing prior art does not specify or make reference to any procedures for datapath interworking being performed at an MPLS/IP interface edge node of an MPLS network.
The present invention attempts to address or alleviate some or all of the foregoing issues by providing a method for the establishment, on a per-circuit, per-call or per-connection basis, of the datapath treatment of a traffic interconnect sourced with a first network and carried over a second network.